Using SSLCipherSuite to restrict to faster cipher algorithms

--00163646babce3dfa6047ac5e1d7
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I have a setup where Apache 2.2.3 is serving a large SVN repository with
WebDAV over HTTPS (using basic authentication).

Everything is working correctly; I would simply like to force usage of
faster cipher algorithms (trading some security in favor of speed) than what
seems to be allowed right now (for instance, AES 256 is used when I connect
with Firefox).

My idea is that, by only allowing less secure but faster algorithms, all SVN
clients (command-line SVN or TortoiseSVN, for instance) will be forced to
use these faster algorithms, thus speeding up SVN operations.

I have played quite a bit with the SSLCipherSuite setting (at the virtual
host level), but I apparently cannot manage to force the client to specific
algorithms (RC4 for instance).

As an experiment, I have tried that (at the virtual host level):

SSLProtocol all -SSLv2
SSLHonorCipherOrder on
SSLCipherSuite ALL:!ADH:+RC4+RSA:!HIGH:!LOW:!EXP:!NULL

which, if I understand correctly, should force usage of RC4+RSA if
available, or other algorithms from the "medium" list:

$ openssl ciphers -v 'ALL:!ADH:+RC4+RSA:!HIGH:!LOW:!EXP:!NULL'
DHE-DSS-RC4-SHA SSLv3 Kx=DH Au=DSS Enc=RC4(128)
Mac=SHA1
KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128)
Mac=MD5
KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128)
Mac=SHA1
RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128)
Mac=MD5
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128)
Mac=SHA1
RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128)
Mac=MD5
RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128)
Mac=MD5

Yet, Firefox still seems to be able to negotiate using AES 256. I am
puzzled.

Am I using the SSLCipherSuite setting correctly? Is there a way (possibly
another way) to achieve this optimization?

For information, I am using Apache/2.2.3 and OpenSSL 0.9.8b 04 May 2006 on
CentOS release 5.2 (Final).

Here is the relevant part of the virtual host configuration:


ServerName svn.mydomain.net:443
ServerAdmin "XXX"

DocumentRoot /var/www/vhosts/mydomain.net/subdomains/svn/httpdocs
CustomLog /var/www/vhosts/
mydomain.net/statistics/logs/access_ssl_log plesklog
ErrorLog /var/www/vhosts/mydomain.net/statistics/logs/error_log

SSLEngine on
SSLVerifyClient none
SSLCertificateFile /usr/local/psa/var/certificates/certVl10777


...


SSLProtocol all -SSLv2
SSLHonorCipherOrder on


DAV svn
SVNPath /var/www/vhosts/mydomain.net/svn/svnrepository
AuthzSVNAccessFile /var/www/vhosts/
mydomain.net/svn/svn-acl-file
Require valid-user
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /var/www/vhosts/mydomain.net/svn/svn-auth-file
SSLRequireSSL



Cheers,
Franz

--00163646babce3dfa6047ac5e1d7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,

Re: Using SSLCipherSuite to restrict to faster cipheralgorithms

François Beaune wrote:
> Hello,
>
> I have a setup where Apache 2.2.3 is serving a large SVN
> repository with WebDAV over HTTPS (using basic authentication).
>
> Everything is working correctly; I would simply like to force usage
> of faster cipher algorithms (trading some security in favor of speed)
> than what seems to be allowed right now (for instance, AES 256 is used
> when I connect with Firefox).

[snip]

> As an experiment, I have tried that (at the virtual host level):
>
> SSLProtocol all -SSLv2
> SSLHonorCipherOrder on
> SSLCipherSuite ALL:!ADH:+RC4+RSA:!HIGH:!LOW:!EXP:!NULL

I noticed that your VirtualHost container doesn't actually contain the
SSLCipherSuite directive. Are you defining that somewhere else, such as
in the global config scope? Double check to make sure that it's being
defined globally as opposed to being wrapped inside another container
object.

Also, you can use this script to check which ciphers are supported by
your site.

http://www.lazorsoftware.com/lazorsoft/files/openssl_check.s h

--
Justin Pasher

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Using SSLCipherSuite to restrict to faster cipher

--0016e659f7b270ac79047ad3b811
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hey Justin,

Thanks for your answer. I did add the various versions of
the SSLCipherSuite directive to my virtual host container, sorry if that
wasn't clear.

In the meantime I found that, by inspecting the handshake between
TortoiseSVN and Apache, the connection does use RC4, which is good. Still,
I don't understand why this doesn't happen with Firefox (it always uses AES
256, which shouldn't be allowed, if I understand things correctly). Any
clue?

Cheers,
Franz


On Tue, Dec 15, 2009 at 8:26 PM, Justin Pasher
wrote:

> Fran=E7ois Beaune wrote:
>
>> Hello,
>>
>> I have a setup where Apache 2.2.3 is serving a large SVN repository with
>> WebDAV over HTTPS (using basic authentication).
>>
>> Everything is working correctly; I would simply like to force usage of
>> faster cipher algorithms (trading some security in favor of speed) than =
what
>> seems to be allowed right now (for instance, AES 256 is used when I conn=
ect
>> with Firefox).
>>
>
> [snip]
>
>
> As an experiment, I have tried that (at the virtual host level):
>>
>> SSLProtocol all -SSLv2
>> SSLHonorCipherOrder on
>> SSLCipherSuite ALL:!ADH:+RC4+RSA:!HIGH:!LOW:!EXP:!NULL
>>
>
> I noticed that your VirtualHost container doesn't actually contain the
> SSLCipherSuite directive. Are you defining that somewhere else, such as i=
n
> the global config scope? Double check to make sure that it's being define=
d
> globally as opposed to being wrapped inside another container object.
>
> Also, you can use this script to check which ciphers are supported by you=
r
> site.
>
> http://www.lazorsoftware.com/lazorsoft/files/openssl_check.s h
>
> --
> Justin Pasher
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server Project=
..
> See for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>

--0016e659f7b270ac79047ad3b811
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hey Justin,

Re: Using SSLCipherSuite to restrict to faster cipher algorithms

François Beaune wrote:
> Hey Justin,
>
> Thanks for your answer. I did add the various versions of
> the SSLCipherSuite directive to my virtual host container, sorry if
> that wasn't clear.
>
> In the meantime I found that, by inspecting the handshake between
> TortoiseSVN and Apache, the connection does use RC4, which is good.
> Still, I don't understand why this doesn't happen with Firefox (it
> always uses AES 256, which shouldn't be allowed, if I
> understand things correctly). Any clue?

Did you try running the shell script to verify that the server is
correctly applying the SSLCipherSuite directive and only offering the
ciphers you have allowed?

http://www.lazorsoftware.com/lazorsoft/files/openssl_check.s h

--
Justin Pasher

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Using SSLCipherSuite to restrict to faster cipher

--0016364c7054c2e0a8047adbd25c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 16, 2009 at 5:03 PM, Justin Pasher
wrote:

> Fran=E7ois Beaune wrote:
>
>> Hey Justin,
>>
>> Thanks for your answer. I did add the various versions of the
>> SSLCipherSuite directive to my virtual host container, sorry if that was=
n't
>> clear.
>>
>> In the meantime I found that, by inspecting the handshake between
>> TortoiseSVN and Apache, the connection does use RC4, which is good. Sti=
ll,
>> I don't understand why this doesn't happen with Firefox (it always uses =
AES
>> 256, which shouldn't be allowed, if I understand things correctly). Any
>> clue?
>>
>
> Did you try running the shell script to verify that the server is correct=
ly
> applying the SSLCipherSuite directive and only offering the ciphers you h=
ave
> allowed?
>
>
> http://www.lazorsoftware.com/lazorsoft/files/openssl_check.s h
>
>
Sorry, I had overlooked your suggestion. Here's the output of the script:

$ ./openssl_check.sh svn.mydomain.net
Checking svn.mydomain.net:443 ...
- DHE-DSS-RC4-SHA
- EXP1024-DHE-DSS-RC4-SHA
+ EXP1024-RC4-SHA at Server public key is 2048 bit
- EXP1024-DHE-DSS-DES-CBC-SHA
+ EXP1024-DES-CBC-SHA at Server public key is 2048 bit
- ADH-AES256-SHA
+ DHE-RSA-AES256-SHA at Server public key is 2048 bit
- DHE-DSS-AES256-SHA
+ AES256-SHA at Server public key is 2048 bit
- ADH-AES128-SHA
+ DHE-RSA-AES128-SHA at Server public key is 2048 bit
- DHE-DSS-AES128-SHA
+ AES128-SHA at Server public key is 2048 bit
- EXP-KRB5-RC4-MD5
- EXP-KRB5-RC2-CBC-MD5
- EXP-KRB5-DES-CBC-MD5
- EXP-KRB5-RC4-SHA
- EXP-KRB5-RC2-CBC-SHA
- EXP-KRB5-DES-CBC-SHA
- KRB5-RC4-MD5
- KRB5-DES-CBC3-MD5
- KRB5-DES-CBC-MD5
- KRB5-RC4-SHA
- KRB5-DES-CBC3-SHA
- KRB5-DES-CBC-SHA
- ADH-DES-CBC3-SHA
- ADH-DES-CBC-SHA
- EXP-ADH-DES-CBC-SHA
- ADH-RC4-MD5
- EXP-ADH-RC4-MD5
+ EDH-RSA-DES-CBC3-SHA at Server public key is 2048 bit
+ EDH-RSA-DES-CBC-SHA at Server public key is 2048 bit
+ EXP-EDH-RSA-DES-CBC-SHA at Server public key is 2048 bit
- EDH-DSS-DES-CBC3-SHA
- EDH-DSS-DES-CBC-SHA
- EXP-EDH-DSS-DES-CBC-SHA
+ DES-CBC3-SHA at Server public key is 2048 bit
+ DES-CBC-SHA at Server public key is 2048 bit
+ EXP-DES-CBC-SHA at Server public key is 2048 bit
+ EXP-RC2-CBC-MD5 at Server public key is 2048 bit
+ RC4-SHA at Server public key is 2048 bit
+ RC4-MD5 at Server public key is 2048 bit
+ EXP-RC4-MD5 at Server public key is 2048 bit
- DES-CBC3-MD5
- DES-CBC-MD5
+ EXP-RC2-CBC-MD5 at Server public key is 2048 bit
- RC2-CBC-MD5
+ EXP-RC4-MD5 at Server public key is 2048 bit
+ RC4-MD5 at Server public key is 2048 bit
- NULL-SHA
- NULL-MD5

I suspect this isn't correct though, as the list stays the same regardless
of how I set SSLCipherSuite (I did restart Apache after each change to
SSLCipherSuite). Either I'm not using the script correctly, or I'm not
setting SSLCipherSuite correctly, or I'm doing another error. Any idea?

Thanks for your help.

Cheers,
Franz

--0016364c7054c2e0a8047adbd25c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

er-left:1px #ccc solid;padding-left:1ex;">
Here is the SSLCipherSuite directive that I use on my servers to lock out i=
nsecure ciphers:



SSLCipherSuite AES256-SHA:DES-CBC3-SHA:AES128-SHA:RC4-SHA:RC4-MD5



Try setting your config to this value. Obviously this is different than wha=
t you are trying to accomplish, but right now the goal is to figure out whe=
ther the SSLCipherSuite directive is actually being acknowledged. When you =
run the openssl_check.sh script again, it should return the following resul=
ts:




=A0+ AES256-SHA at Server public key is 1024 bit

=A0+ AES128-SHA at Server public key is 1024 bit

=A0+ DES-CBC3-SHA at Server public key is 1024 bit

=A0+ RC4-SHA at Server public key is 1024 bit

=A0+ RC4-MD5 at Server public key is 1024 bit

=A0+ RC4-MD5 at Server public key is 1024 bit

ex;border-left:1px #ccc solid;padding-left:1ex;">If you see anything differ=
ent, then the SSLCipherSuite is not being set properly. Double check that y=
ou don't have multiple SSLCipherSuite directives set across different f=
iles. Also make sure you are not accidentally setting it within an unintent=
ional container, such as <Directory> or <VirtualHost>. I know t=
hat on CentOS, the default config file that has the SSL directives actually=
contains the SSLCipherSuite directive within a <VirtualHost> contain=
er. That threw me off recently when I was trying to setup apache on a CentO=
S box for the first time.

Re: Using SSLCipherSuite to restrict to faster cipher algorithms

François Beaune wrote:
> On Wed, Dec 16, 2009 at 7:00 PM, Justin Pasher
> > wrote:
>
> [snip]
>
> Here is the SSLCipherSuite directive that I use on my servers to
> lock out insecure ciphers:
>
> SSLCipherSuite AES256-SHA:DES-CBC3-SHA:AES128-SHA:RC4-SHA:RC4-MD5
>
>
> I'm still getting the same list, even if I use the SSLCipherSuite you
> suggested, so it's clearly not used.
>
> On my side (in my subdomain's configuration), I only have one
> SSLCipherSuite occurrence, inside the container I shown
> earlier in this thread (and it's not in a or
> container).
>
> That being said, in /etc/httpd/conf.d/ssl.conf, there is another
> occurrence:
>
>
> ...
> SSLEngine on
> SSLProtocol all -SSLv2
> SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
> ...
>
>
> Shouldn't my configuration file have precedence over that?

So now we know how Firefox is still using AES256. It's just a matter of
figuring out why the SSLCipherSuite is not being used. The first thing
I'd try is replacing the SSLCipherSuite directory you found above
(inside the container). If that fixes the
problem, then you at least know where it's picking up the setting. As
far as WHY it's hitting that VirtualHost container, Apache should be
falling back to that one if there is no other matching
container for the request. Looking back at the original post, I see this...


ServerName svn.mydomain.net:443
....


So I assume that the request is actually being made to the (masked) IP
address XXX.XXX.XXX.XXX? One thought out from left field would be that
the box has multiple IP addresses assigned and the request is actually
hitting YYY.YYY.YYY.YYY instead of XXX.XXX.XXX.XXX, which would make it
fall back to the default VirtualHost:443, I believe. Also, if you are
trying to access the server via localhost, that would be coming from a
different IP address (127.0.0.1), so it would also fall back to the
default. Additional note: you don't need the ":443" on the ServerName.

Now, if changing the SSLCipherSuite in the default VirtualHost does NOT
register the change, then it would sound like it's not hitting ANY of
the VirtualHost containers that have SSLCipherSuite defined. If that
really is the case, you could always put the SSLCipherSuite in the
global scope as a last resort, but ideally you could figure out why it's
not recognizing the setting.

--
Justin Pasher

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Using SSLCipherSuite to restrict to faster cipher

--002215b01c4a8bc81f047b925e81
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 17, 2009 at 6:21 PM, Justin Pasher
wrote:

> Fran=E7ois Beaune wrote:


[snip]


> I'm still getting the same list, even if I use the SSLCipherSuite you
>> suggested, so it's clearly not used.
>>
>> On my side (in my subdomain's configuration), I only have one
>> SSLCipherSuite occurrence, inside the container I shown
>> earlier in this thread (and it's not in a or
>> container).
>>
>> That being said, in /etc/httpd/conf.d/ssl.conf, there is another
>> occurrence:
>>
>>
>> ...
>> SSLEngine on
>> SSLProtocol all -SSLv2
>> SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
>> ...
>>
>>
>> Shouldn't my configuration file have precedence over that?
>>
>
> So now we know how Firefox is still using AES256. It's just a matter of
> figuring out why the SSLCipherSuite is not being used. The first thing I'=
d
> try is replacing the SSLCipherSuite directory you found above (inside the
> container). If that fixes the problem, then y=
ou
> at least know where it's picking up the setting. As far as WHY it's hitti=
ng
> that VirtualHost container, Apache should be falling back to that one if
> there is no other matching container for the request. Looki=
ng
> back at the original post, I see this...
>
>
>
> ServerName svn.mydomain.net:443
> ...
>
>
> So I assume that the request is actually being made to the (masked) IP
> address XXX.XXX.XXX.XXX? One thought out from left field would be that th=
e
> box has multiple IP addresses assigned and the request is actually hittin=
g
> YYY.YYY.YYY.YYY instead of XXX.XXX.XXX.XXX, which would make it fall back=
to
> the default VirtualHost:443, I believe. Also, if you are trying to access
> the server via localhost, that would be coming from a different IP addres=
s
> (127.0.0.1), so it would also fall back to the default. Additional note: =
you
> don't need the ":443" on the ServerName.
>
> Now, if changing the SSLCipherSuite in the default VirtualHost does NOT
> register the change, then it would sound like it's not hitting ANY of the
> VirtualHost containers that have SSLCipherSuite defined. If that really i=
s
> the case, you could always put the SSLCipherSuite in the global scope as =
a
> last resort, but ideally you could figure out why it's not recognizing th=
e
> setting.
>


Getting back to this problem only now.

I tried changing the SSLCipherSuite directive in /etc/httpd/conf.d/ssl.conf
(in the container), but that had no effect.
However, I also tried adding a global SSLCipherSuite directive outside any
container, and that had the intended effect:

$ ./openssl_check.sh svn.mydomain.net
Checking svn.mydomain.net:443 ...
- DHE-DSS-RC4-SHA
- EXP1024-DHE-DSS-RC4-SHA
- EXP1024-RC4-SHA
- EXP1024-DHE-DSS-DES-CBC-SHA
- EXP1024-DES-CBC-SHA
- ADH-AES256-SHA
- DHE-RSA-AES256-SHA
- DHE-DSS-AES256-SHA
+ AES256-SHA at Server public key is 2048 bit
- ADH-AES128-SHA
- DHE-RSA-AES128-SHA
- DHE-DSS-AES128-SHA
+ AES128-SHA at Server public key is 2048 bit
- EXP-KRB5-RC4-MD5
- EXP-KRB5-RC2-CBC-MD5
- EXP-KRB5-DES-CBC-MD5
- EXP-KRB5-RC4-SHA
- EXP-KRB5-RC2-CBC-SHA
- EXP-KRB5-DES-CBC-SHA
- KRB5-RC4-MD5
- KRB5-DES-CBC3-MD5
- KRB5-DES-CBC-MD5
- KRB5-RC4-SHA
- KRB5-DES-CBC3-SHA
- KRB5-DES-CBC-SHA
- ADH-DES-CBC3-SHA
- ADH-DES-CBC-SHA
- EXP-ADH-DES-CBC-SHA
- ADH-RC4-MD5
- EXP-ADH-RC4-MD5
- EDH-RSA-DES-CBC3-SHA
- EDH-RSA-DES-CBC-SHA
- EXP-EDH-RSA-DES-CBC-SHA
- EDH-DSS-DES-CBC3-SHA
- EDH-DSS-DES-CBC-SHA
- EXP-EDH-DSS-DES-CBC-SHA
+ DES-CBC3-SHA at Server public key is 2048 bit
- DES-CBC-SHA
- EXP-DES-CBC-SHA
- EXP-RC2-CBC-MD5
+ RC4-SHA at Server public key is 2048 bit
+ RC4-MD5 at Server public key is 2048 bit
- EXP-RC4-MD5
- DES-CBC3-MD5
- DES-CBC-MD5
- EXP-RC2-CBC-MD5
- RC2-CBC-MD5
- EXP-RC4-MD5
+ RC4-MD5 at Server public key is 2048 bit
- NULL-SHA
- NULL-MD5

It's basically the list you mentioned (except for the size of the public
keys).

So, it looks like none of the SSLCipherSuite directives inside virtual host
containers have any effect, only the global one has.

What I don't understand is that the other directives do have an effect. Fo=
r
instance, the block defined in the XXX.XXX.XXX.XXX:443> container is definitely taken into account, as my SVN
repository is properly served by Apache (everything is working perfectly).
Similarly, at some point I added LimitRequestBody and LimitXMLRequestBody
directives to this virtual host container, and they had the intended effect=
..
Why would it be different for SSLCipherSuite?

Thanks for your help.

Cheers,
Franz

--002215b01c4a8bc81f047b925e81
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable